Users of a media network, such as a cable network have access to a plurality of programming options. Depending on the particular arrangement between the user and a network operator, the user may purchase various programming channels and options. A set-top terminal (STT) may be utilized to communicate with the media network to provide programming and options that the user has purchased. As the network operator generally tries to prevent unauthorized access to unpurchased channels and options, the STT may be configured with various authentication and/or encryption capabilities. As a nonlimiting example, many STTs may be configured with a secure processor, which may act as a physically secure environment for facilitating access to the purchased channels and options.
While historically, the secure processor has been configured with conditional access logic that is unchangeable subsequent to manufacture, many STTs are now being configured with one or more secure processors that are configured to receive conditional access logic updates and/or different conditional access logic from the logic currently stored. When such changes are made to the secure processor, however, other components, such as a host may also have logic that communicates with secure processor. As various components of the conditional access logic in the secure processor have changed, logic in the host may also change in order to communicate with the new conditional access logic. Since updating the host may involve knowledge of the new conditional access logic, as well as the capabilities of the particular system utilizing the new conditional access logic, many problems can arise in utilizing the new conditional access logic in this manner.
More specifically, at least one current approach includes host software and one or more secure processor client designed for a specific network and conditional access. This approach may reduce ability to produce a “generic” set-top box that can be configured to operate on an arbitrary network. One solution to this dilemma has been to divide set-top functionality between two separable modules. However, this solution can be more expensive because interface hardware and software are generally connected to these separable modules.
Generally speaking, there may be three components in a set-top terminal that may be network-specific: the code inside the secure processor, non-time-critical host code (which may be utilized for configuring network access, and/or other advanced features), and time-critical host code, which can be configured to communicate with the secure processor to obtain the control words necessary to decrypt content streams in real time. All of these elements may be part of the conditional access system (CAS) code on the host device. Downloading network-specific or CAS-specific host logic may not be desired. Since there are many different possible host platforms, each CAS provider would need to write code tailored to each specific host, which is in the general case intractable. One current solution involves an interpreter (such as a JAVA interpreter), and the network-specific portions can be written in JAVA or some other agreed-upon host-independent language. This solution may not be suitable for time-critical functions, however.
Thus, a heretofore unaddressed need exists in the industry to address the aforementioned deficiencies and inadequacies.